Since the premise of our book is that security is a concern when discussing cloud
computing, let’s revisit the security considerations we previously
discussed and conclude with our thoughts on the current and future states
of these considerations for the cloud:Infrastructure security
Data security and storage
Identity and access management
Security management
Privacy
Audit and compliance
Security-as-a-[cloud] service
Impact of cloud computing on the role of corporate IT
1. Infrastructure Security
During our discussion of infrastructure security, we looked at
network-, host-, and application-level security and the issues
surrounding each level with specific regard to cloud computing. At the
network level, although there are definitely security challenges with
cloud computing, none of those challenges are caused specifically by
cloud computing. All of the network-level security challenges associated
with cloud computing are instead exacerbated by cloud computing, not
specifically caused by it. Likewise, security issues at the host level,
such as an increased need for host perimeter security (as opposed to
organizational entity perimeter security) and secured virtualized
environments, are exacerbated by cloud computing but not specifically
caused by it. And the same holds true for the application level.
Certainly, there is an increased need for secure software development
life cycles due to the public-facing nature of (public) cloud
applications and the need to ensure that APIs have been thoroughly
tested for security, but those application-level security requirements
are again exacerbated by cloud computing and not specifically caused by
it.
Therefore, the issues of infrastructure security and cloud
computing are about understanding which party provides which aspects of
security (i.e., does the customer provide it or does the CSP provide
it)—in other words, defining trust boundaries.
With regard to infrastructure security, an undeniable conclusion
is that trust boundaries between customers and CSPs have moved. When we
see poll after poll of information executives (e.g., CIOs) and
information security professionals (e.g., CISOs) indicating that
security is their number one concern with cloud computing, the primary
cause for that concern is really over moved trust boundaries. To be more
specific, the issue is not so much that the boundaries have moved, but
more importantly that customers are unsure where those trust boundaries
have moved to. Many CSPs have not clearly articulated those trust
boundaries (e.g., what security is provided by the CSP versus what
security still needs to be provided by the customer), nor are those new
trust boundaries reinforced in operational obligations such as
service-level agreements (SLAs).
Although the CSPs have the primary responsibility for articulating
these new trust boundaries, some current confusion about this is also
the fault of information security personnel. There are some information
security professionals who, either fearing something new or not fully
understanding cloud computing, are engaging in FUD (fear, uncertainty,
and doubt) with their business customers.
Similar to confusion over moved trust boundaries is the fact that
the established model of network tiers or zones no longer exists. That
model has been replaced with domains, which are less precise and afford
less protection than the old model. (Domain names are used in various
networking contexts and application-specific naming and addressing
purposes based on DNS.) If we can no longer trust the network
(organizational) perimeter to provide sufficient protection and are now
reliant on host perimeter security, what is the trust model between
hosts?
An analogy of this problem already exists and was dealt with 20
years ago—STU- (Secure Telephone Unit) IIIs used by the U.S. Department of Defense and the
intelligence community. In that model, each STU-III unit (a host) was
responsible for its own “perimeter security” (i.e., the device’s
electronic components were tamper-resistant), and each device had a
secure authentication mechanism (i.e., a dongle with an identity written
to it, protected and verified by asymmetric encryption and Public Key
Infrastructure or PKI). Additionally, each device would negotiate a
common level of authorization (classification level) based on an
attribute included with the identity in the dongle.
Today, we have no such model in cloud computing. The STU-III model
simply is not viable for cloud computing, and there is no trusted
computing platform for virtual machine (VM) environments. Therefore,
host-to-host authentication and authorization is problematic in cloud
computing since much of it uses virtualization. Today the use of
federated identity management is focused on trust, identity, and
authentication of people. The identity management solutions of today do
assist in managing host-level access; however, there is no viable
solution today that addresses the issue of host-to-host trust. The
host-to-host trust issue is exacerbated in cloud computing because of
the sheer number of resources available.
Conceptually similar to the trust boundary problem at the
application level is ensuring that one customer’s data is not
inadvertently provided to another, unauthorized customer. Data has to be
securely labeled to ensure that it remains separated among customers in
a multitenancy environment. Today, data separation in cloud computing is
logical, not physical, as was done previously, and there are valid
concerns about the adequacy of that logical separation.
2. Data Security and Storage
During our discussion of data security and storage, we looked at several aspects of
data security and the storage of data. If cloud computing customers are
concerned about the security afforded by infrastructure security and are
counting on data security to provide compensating controls, those
customers will be disappointed. A major reason for the lack of effective
data security is simply the limitations of current encryption
capabilities. However, efforts to adequately detail data lineage
(mapping) are simply not possible in today’s cloud computing offerings.
The amount of effort (and cost) to provide such mapping runs counter to
the economic incentives of cloud computing. Another major problem with
current cloud computing offerings is a lack of serious attention
(effective action) to customers’ concerns about data remanence (i.e.,
data residue left behind and possibly becoming available to unauthorized
parties).
These concerns with data security do not negate the capabilities
or advantages of utilizing storage-as-a-service in the cloud—for
non-sensitive, non-regulated data. If customers do want to (simply)
store organizational data in the cloud, they must take explicit actions,
or at least verify that the provider will and can adequately provide
such services, to protect their data stored in the cloud.
We know how to effectively encrypt data-in-transit, and we know
how to effectively encrypt data-at-rest. But because encrypted data
cannot be processed, indexed, or sorted, to do any of those important
activities requires that the data be unencrypted—hence, a security
concern, especially if that data is in the cloud and is beyond the data
owner’s direct control.
Even efforts to effectively manage data that is encrypted are
extremely complex and troublesome due to the current inadequate
capabilities of key management products. Key management in an
intra-organizational context is difficult enough; trying to do effective
key management in the cloud is frankly beyond current capabilities and
will require significant advances in both encryption and key management
capabilities to be viable. Claims of key management products being
effective currently are naïve at best.
